E-mail probably is the most common Internet service, one that many of us rely on for day-to-day communication. From a security perspective, the e-mail system is a bit more complicated than the Web. When you use the Web, the process involves you and the Web server. But when you send e-mail, intermediaries are involved as well.
When you send an e-mail message, that message is transferred, usually using the Simple Mail Transfer Protocol (SMTP), from your machine to a mail server (Figure 5.5). That server usually is operated by your ISP or by a Web-mail site, if you use services such as Yahoo! Mail or Hotmail. Your ISP’s mail server is responsible for delivering that message to the recipient’s mail server, which usually is operated by the recipient’s ISP or a Web-mail site. The recipient’s mail server holds the mail until the recipient checks his or her mail; at that time, the mail is delivered. Under some conditions, additional intermediate mail servers may be involved.
Figure 5.5 Sending e-mail involves several intermediaries, making the system more complex and difficult to secure.
At least four entities usually are involved in sending an e-mail message: you, your ISP’s mail server, the recipient’s mail server, and the recipient. A message also can have multiple recipients. To simplify matters, however, we’re going to consider e-mail security from just two perspectives: what you send and what you receive.
Sending your e-mail password
In Chapter 4, we showed you how to choose, manage, and maintain good passwords. We want to expand on that advice in this section as it applies to the password you use to check your e-mail.
Your e-mail password is sent to your e-mail server when you log in to read your e-mail. The password prevents someone else from pretending to be you and reading your e-mail—and that’s about all it does. You may think that your e-mail password prevents someone else from sending mail as you as well, but that usually isn’t the case. A hacker has several ways to send e-mail as you if he really wants to. (See “Sending e-mail securely” later in this chapter if you want to be sure that only you can send e-mail as you.)
Your e-mail password does prevent other people from reading your e-mail, which is something you do want. But reading e-mail is as much a privacy issue as it is a security issue. Your online safety may not be compromised if someone reads your e-mail, especially if you follow the practices described later in this chapter. As long as you don’t reuse your e-mail password for more critical services and don’t save it on a notebook computer that you travel with, you don’t need to worry about many other e-mail password-management issues.
As is the case with Web-server passwords and other data, e-mail passwords can be sent securely or insecurely to an e-mail server. An e-mail password is considered to be sent insecurely if anyone spying on Internet communications can look at it. Insecure e-mail passwords generally are less of a security risk than insecure Web-site passwords are, and not simply because someone can do more damage by logging in as you on a Web site than by reading your e-mail. Usually, your e-mail server is provided by your ISP, so logging in to read your e-mail usually doesn’t involve Internet-wide communication. The communication is between you and your ISP, so hackers have much less opportunity for spying.
Regardless of the lower risk, making your e-mail password as secure as possible is still good practice. Most e-mail applications and e-mail servers provide a way of sending your password securely through a protocol called APOP (Authenticated Post Office Protocol). APOP encrypts your password to make it difficult to read (although not as difficult as the Web’s SSL). You should select this option if it’s supported by your e-mail application and server (Figure 5.6). Mac OS X’s built-in Mail application automatically uses APOP if it’s supported by your mail server.
Figure 5.6 You should always select Eudora’s APOP option if it’s supported by your e-mail server
If you use one of the popular Web-mail services, you should take a few extra precautions with your e-mail password. Services such as Yahoo! Mail and Hotmail use Web pages and forms to let you read and send e-mail through your Web browser, rather than through a dedicated e-mail application. Apple’s .Mac e-mail service has Web-based features as well.
Because some Web-mail services do not support secure passwords, you should check the security of your password by looking at the icon in your browser window.
Many Web-mail systems also use your password for other services, even if you don’t want them to, so keep that in mind when you choose and maintain your e-mail password. Your .Mac password, for example, also is used as the password to your iDisk online storage (see Chapter 3 ). That service could contain significantly more important data than your e-mail service, because you can use that storage for anything. Unlike some other Web-mail systems, Apple recognizes the potential additional risk of password reuse and transmits passwords securely through the .Mac site.
Finally some e-mail services now require your password for sending as well as receiving mail, especially if you are not on your “home” network. Generally called “SMTP” or “outgoing” authentication, the use of your password for sending mail makes it more difficult (but still far from impossible) for others, in particular spammers, to send e-mail as you. Most e-mail programs include a way to configure SMTP authentication (Figure 5.7).
Figure 5.7 Configuring Mac OS X Mail to provide your password when sending e-mail
Sending e-mail
Your e-mail password is a small but important piece of data that you send through your e-mail application. Most of the rest of what you send through that application (or a Web-mail system) is outgoing e-mail. Protecting outgoing e-mail is both a privacy and a security issue. If people are spying on the e-mail that you send, they might find out things that you don’t want them to know but that don’t affect your security directly. But they also can find out things that do affect your security directly.
Keep in mind one simple fact about sending (and receiving) e-mail:
At least on the Web, most Web pages that need to be secure can be. With e-mail, this option is available in few situations, and sending data in those situations is usually difficult. (See “Sending e-mail securely” later in this chapter for some emerging options, however.) This general lack of security leads to another simple rule for sending e-mail:
Never send credit-card numbers, passwords for other services, or other confidential data by e-mail. You don’t know who’s going to be watching.
You may think it’s highly unlikely that anyone is watching when you send your e-mail. But automated spying applications can pick up things such as credit-card numbers and passwords. If you go to all the trouble of choosing and maintaining a good password for an important service, and then send that password out through e-mail, you may have done a lot of work for nothing.
With the recent emphasis on Internet security, you would think that e-mail would be more secure. The situation is beginning to change: Secure e-mail options are emerging. One limiting factor with secure e-mail, however, is that it requires the participation of different entities. Not only do the sending and receiving e-mail applications need to support it but the sending and receiving e-mail servers often must support it as well. Therefore, secure e-mail is a complicated subject—one that is too complex for many of us.
Secure e-mail is encrypted in such a way that anyone spying on the message as it’s sent can’t read it easily. The secure message can also include features beyond basic encryption, such as those enabling authentication and integrity checking of the message. These features assure the recipient that the message really came from you and was not tampered with by an intermediary. The combination of encryption, authentication, and integrity results in a powerful set of features. Just as with secure Web sites and credit cards, secure email actually makes a Net-based service more secure than its physical world equivalent.
Usually, secure e-mail uses a digital certificate of some sort, much like the Web’s SSL. In fact, SSL is one of the emerging options for secure e-mail through something called SSL/POP. Like a Web server, your ISP’s e-mail server can use a digital certificate to prove to you that it’s really your ISP’s server and to encrypt your e-mail. Unlike most Web servers, however, your e-mail server then needs to forward your e-mail to another e-mail server, which needs to deliver that e-mail to its intended recipient (Figure 5.5). The odds are that the other e-mail server and the recipient don’t support SSL yet, so your message will be only partially protected (between you and your ISP, which probably is the path that least needs protecting). As more applications and providers start to use SSL, this option may make more sense.
Digital certificates are also used in a secure e-mail scheme called S/MIME (Secure/Multipurpose Internet Mail Extensions). With S/MIME, both the sender and receiver of the e-mail message usually obtain personal digital certificates from a company such as Verisign. The sender uses his or her certificate to sign the e-mail digitally before sending it out. The receiver of the e-mail can check the sender’s certificate against the message to confirm that the e-mail really came from the sender and that it was not tampered with during transmission (by an intermediate mail server, for example). The receiver’s certificate is not used during this authentication process, but it will be used later if the sender wants to encrypt the e-mail as well as sign it.
Without a technique such as S/MIME or some other form of authentication, hackers can easily make e-mail look as though it came from you or anyone else. All they have to do is enter any person’s name and e-mail address in an e-mail application, create an e-mail, and send it. Many e-mail servers prevent e-mail from being sent from fake e-mail addresses, but others don’t. A hacker needs to find just one server anywhere on the Net to send a forged message—or he can simply run one himself.
In addition to sending authenticated e-mail, S/MIME can send encrypted e-mail. That process is tricky, because the sender of the message needs to have the intended recipient’s certificate first. If the sender used his or her own certificate to encrypt the message, anyone could decrypt it, just as anyone can verify the sender’s signature. In other words, the party that wants to receive encrypted e-mail drives the process, not the party that wants to send it. This setup is the opposite of how authentication through S/MIME works.
The sender uses the recipient’s certificate to generate a key and encrypt the e-mail so that only the recipient can read the message. This process is similar to the digital scrambling used in SSL. Messages sent with S/MIME can be both signed and encrypted if the sender has his own certificate and the receiver’s certificates available. If you frequently send important messages to a particular party, it’s worth the effort to find an e-mail application that supports S/MIME (such as the Mac OS X Mail application) and exchange certificates. Recent versions of Mac OS X will even automatically store S/MIME certificates in your keychain.
For S/MIME to work, both the sender’s and receiver’s e-mail applications must support the technology, but the e-mail servers in the middle do not need to support it. S/MIME works within the Internet’s standard e-mail protocols, simply encoding the data in the messages that are being sent. By using the standard protocols, S/MIME eliminates the need for any changes in the e-mail servers, which still are passing standard messages.
PGP (Pretty Good Privacy) is another secure e-mail scheme. PGP works much like S/MIME, except that it doesn’t use digital certificates; instead, it uses a public-key/private-key pair. When you start using PGP, it generates this pair for you. As the names imply, you keep your private key secret but let anyone know what your public key is. In reality, your public key (like a digital certificate) is a long series of letters and numbers, so you end up storing it in a file somewhere, as you do with your private key. Because your public key is designed to be public, it contains no information that would compromise the secure e-mail process (that is, no secret information). You can send your public key to other people by insecure e-mail or post it on a Web site. Even key servers and other public directories list the public keys of many PGP users (as well as the certificates of S/MIME users, for that matter).
Senders use their private keys to sign e-mail, similar to the way that they would use their certificates with S/MIME. The receiver’s e-mail application must support PGP to verify that the e-mail is from the sender and has not been compromised. (PGP sends enough information with the message to allow the receiver to make this verification.) A sender can also use someone else’s public key to send encrypted e-mail, just as they would use someone’s certificate in S/MIME. As is the case with S/MIME, both the sender’s and receiver’s applications must support PGP (a Eudora or Mail plug-in provides this support, for example), but the e-mail servers in the middle don’t need to do anything special.
While sending e-mail, you are at risk of giving away information that you may not want to give away, such as your password or the contents of the e-mail. But the actual risk of access to or destruction of information on your machine, or of misuse of your machine, is low. These risks are much higher when you’re receiving e-mail.
For security purposes, understanding the difference between the body of an e-mail message and any attachments to that message is important. The body of a message is the text part of the e-mail that’s displayed by your e-mail application; it poses very little security risk (although see the mention in the next section about HTML e-mail). Attachments, however, are a different story. Attachments are independent files included with (or attached to) the body of the e-mail. They’re like photographs included with a letter. Attachments usually are opened and displayed by an application other than your e-mail reader and can even be applications themselves, which is where much of the security risk associated with them comes in.
When you receive an e-mail with an attachment, your e-mail application will display the body of the e-mail. It will not display the attachment, because it usually doesn’t know how. Instead, it will indicate that the e-mail includes an attachment. Different e-mail applications indicate attachments in different ways (see Figures 5.8, 5.9, and 5.10).
Figure 5.8 A Eudora inbox including messages with attachments
Figure 5.9 A Eudora message with an attachment
Figure 5.10 A Mac OS X Mail message with an attachment
Make sure you understand how your e-mail application indicates an attachment, because attachments are how a good percentage of the malicious work on the Internet is performed. When you understand how to spot an attachment, follow one simple rule when you receive one:
Do not open e-mail attachments except under rare conditions. In most cases, delete them without opening them.
If you’ve sent and received a lot of e-mail, this rule may seem like a rather radical and drastic approach. After all, you probably have sent and received attachments in the past without problems. Attachments have been a useful feature of e-mail for a long time. Unfortunately, the feature has been too useful and has been co-opted by hackers in numerous ways. Attachments provide a convenient and seemingly innocuous way for a hacker to get a specially written application or script running on your machine. And after hackers have their application running on your machine, they own your machine from a functional perspective. They can access all your files; spy on your passwords; and even send e-mail as you, further propagating the mischief. (See Chapter 11 for details on self-propagating e-mail viruses.)
When an attachment first comes in to your e-mail application, it is inert. If you open an attachment (usually, by double-clicking it), that attachment is activated as though you had double-clicked it in the Finder. If the attachment is simply a document that needs another application to be displayed, the associated application launches to display the document. In these cases, because the application is already on your machine, not much additional risk is involved. (But you should look out for certain script- and macro-based viruses; see Chapter 11.) Many times, however, the attachment can be an application, in which case opening it results in that application being run on your machine. Even if the attachment doesn’t look like an application and even if it appears to be named something like picture.jpg or document.txt, it still could be an application. You can’t be sure.
The fact that you don’t want to run someone else’s application on your machine probably is obvious, but it may not be obvious that you’ve done so. Because a malicious application usually wants to take control of your machine without your knowing about it, that application probably will do something to trick you into thinking that nothing bad happened. It may display a picture or a funny animation. It may return a fake error, saying that something went wrong and the attachment couldn’t be opened. But what it really did is something that you won’t notice and may not notice for some time, if at all.
How do you know whether it’s OK to open an attachment? After all, attachments may be sent legitimately. You should do so only under rare circumstances. You should never open an attachment from someone you don’t know, for example, regardless of what the e-mail body says. If you’re really interested, you should write the sender back and ask for more details, but continue to be wary of this type of ongoing conversation, keeping in mind how it started (just as you would in the physical world if someone you didn’t know came up to you on the street or knocked on your door).
If you know the person who’s sending the attachment, opening it is OK, right? Wrong. Remember what we’ve said about how insecure email is. Someone might easily have forged the e-mail to trick you into opening the attachment. Another not-unlikely scenario is that someone co-opted your friend’s machine when he or she opened the attachment, causing you to be sent the e-mail containing that attachment. Many recent viruses have spread this way, with people propagating them because they knew the sender and thought it was OK to open the attachment (see Chapter 11 for details).
If you unexpectedly receive an attachment from someone you know, you probably will want to talk with that person before opening the attachment unless the body of the e-mail makes it clear that the attachment is legitimate. But just because the body says something like “check the attachment,” it may not be legitimate. The body should make it clear that the sender meant to send both the e-mail and the attachment. The body should contain something specific that a virus couldn’t generate automatically, such as the time of an upcoming meeting or some specific personal information. And think carefully before concluding that a virus couldn’t have generated the information. Certain recent viruses, for instance, have used your ISP’s domain name in the body of the message, claiming something like “here’s a message from the opendoor.com staff.”
Suppose that the attachment came from someone you know and is expected, or that the context of the e-mail makes it clear that the person sending the attachment really meant to send it. Surely it’s OK to open the attachment, right? Maybe. Attachments, even if not sent by a virus, still carry risks of viruses. If the machine that sent the e-mail has a virus, that virus could be passed on through the attachment. Be sure that you have the proper antivirus software installed on your machine before opening the attachment. See Chapter 11 for all the details.
Here’s a checklist for what to do if you receive an e-mail with an attachment:
If the e-mail is from someone you don’t know, delete the attachment. Follow up with the sender if you want, but be cautious about any conversation that begins this way.
If the e-mail is from someone you know but is unexpected, read the message carefully. Try to make sure that the sender really meant to send you the attachment. If you have any doubt, talk with the sender to be sure. If the sender has any doubt, delete the attachment.
If the e-mail and attachment are expected, be sure that you have up-to-date antivirus software installed on your machine before opening the attachment.
Always delete the attachment if you have any concerns about it, because if you leave it around, you might open it accidentally later. Some e-mail applications do not necessarily delete the attachment if you delete the e-mail message, so check your e-mail application’s preferences to be sure. Eudora, for example, does not delete attachments when you delete the associated message, although you can enable this feature as shown in Figure 5.11. Mac OS X Mail, on the other hand, keeps the attachment with the e-mail message until you double-click or save that attachment (double-clicking automatically saves it in Mail’s download folder). After that, Mail provides a number of options for when the attachment should be deleted. If your e-mail application does not delete attachments with messages, you’ll have to find the attachment and drag it to the Trash separately.
Figure 5.11 The attachments section of Eudora’s Settings dialog box
As a corollary to the rules about receiving attachments, think twice before sending attachments, because the person receiving the attachment is going to have to perform the same set of checks as you would (or should have to do so, anyway). Can you convey the same information without an attachment? Maybe you can include it in the body of the e-mail message. Or maybe you can point the recipient to a Web site that has the information or to a file on an office server somewhere (although risks of viruses still apply if the file is downloaded from a server). If you really feel that you must send an attachment, be sure to include enough context in the body of the e-mail message to make it clear that you intended to send the attachment. Instead of saying something like “Check out this file,” be more specific. Say something like “Please review this proposal for the Kingsford project before we meet tomorrow.” You would feel a lot better if you had such details, and they should make the recipient feel better as well.
Other issues with receiving e-mail
Part of the problem with receiving attachments is that you can’t be sure that the e-mail is from the person or organization it claims to be from or whether they really intended to send it. This problem applies beyond attachments. You should consider any e-mail that you receive as suspect in this regard, even if it includes no attachment. Before acting on the information included in an e-mail, think about what would happen if the e-mail was forged or sent by a virus on the sender’s machine. Is the e-mail asking you to disclose any information or take any action that would result in compromised security? An example would be an e-mail message from a trusted friend or colleague, asking for your credit-card number or password. Or perhaps a message asks you to disable your machine’s firewall or other form of enhanced security temporarily.
If you have any doubts about the legitimacy of an e-mail, talk with the sender. You would know better than to ask for a password via e-mail, and the sender should, too. (And if senders don’t know any better, it’s probably time that they did.) Talking with the sender will, at minimum, help increase overall security.
On a related note, be on the lookout for anyone who sends you confidential information through e-mail. If you are ever assigned the password to a service through e-mail, for example, get back to the sender and ask for another password through a more secure channel. (Better yet, tell the sender what password you’d like to receive through a secure channel.) Not everyone will be as well schooled in security issues as you are.
You should also be suspicious of any Web-page links included in any e-mail messages that you receive. In particular, be sure to read about “phishing” schemes in the following section.
A related issue is the capability to send and receive mail formatted using HTML (Hypertext Markup Language). Generally, HTML provides an advanced way of formatting e-mail text, allowing features such as boldface and font sizes, plus the inclusion of photographs and graphics in the body of the message. But advanced HTML can carry some security risks. A link in an HTML e-mail could go to a page on a Web site that downloaded and ran a Java application on your machine. The HTML would obscure the actual details of the link, so you wouldn’t know exactly where you were going. Be extremely cautious about clicking links in HTML e-mail.
Another potential security problem with HTML e-mail is JavaScript. If your e-mail application supports JavaScript, you might want to consider disabling its use on all incoming e-mail, probably through a Preferences or Settings menu item. Use of JavaScript in HTML e-mail is quite new, and probably will be subject to security exploits in the future, so better safe than sorry.
As users become more savvy about security issues relating to both the Web and e-mail, hackers have to develop more sophisticated schemes to continue their evil ways. “Phishing” combines use of the Web and e-mail in an attempt to get you to disclose confidential information. Here’s how phishing works:
An hacker forges an email from a commercial organization, often a bank or stock broker. The email appears to come from that organization in multiple ways:
· Its forged “from” address contains the domain name of the organization.
· Its body makes specific reference to aspects of the organization’s business, including, for instance, an actual address, an ongoing promotion, etc.
· The e-mail may even include official-looking graphics, mottos and legal notices.
The real tell-tale sign of a phishing e-mail, however, is that it will contain a link to what appears to be a legitimate Web site for that organization, and it will ask you to click on that link. And when you click on that link, it will take you to a professional-looking, secure site that appears in almost all ways to be the site of that organization. But of course the site will in fact be a fraudulent “front” whose purpose is to get you to enter confidential information such as your bank account number or password, which it will immediately pass on to the evil doer.
So how can you distinguish a legitimate email from a phishing one?
It is by far safest to simply assume that any Web site link sent in an e-mail is suspect, and to never enter confidential information into any site that you get to through such a link. Due to the risks involved, most legitimate organizations would never send you such an e-mail.
If you want to go further, here are some additional ways you can try to detect phishing e-mails:
· After clicking on the Web site link, check your browser’s location bar to make sure you went to the site you expected to. Also, obtain the organization’s Web address through other means (like Google) and make sure that’s where you ended up.
· Some email applications, like Eudora, will automatically flag suspect links (Figure 5.12).
· Obtain the organization’s phone number from somewhere other than the Web site and call them.
Figure 5.12 A phishing warning from Eudora
Beware that some phishing schemes even include randomly generated information, such as names or account numbers, which will in most cases be wrong. Since the schemes send out so many e-mails, however, they’re counting on being right enough of the time to convince at least a few of the recipients of their legitimacy.
As a further example of the lengths hackers can go to with phishing schemes, it was discovered that various browsers (including versions of Safari up through 1.2.4) could be tricked into displaying Web addresses that looked legitimate but in fact included foreign characters that simply appeared just like English ones. Newer browsers flag such characters specifically.